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METHOD FOR ISSUING AN ELECTRONIC IDENTITY 

BACKGROUND OP THE INVENTION 

Field of the invention 

The present invention relates no electronxc 
identity techniqxies and methods- More particularly the 
present invention relates to a novel and improved 
method and system for requesting and issuing an elec- 
tronic identity based on previously certified elec- 
tronic Identity. 

Dascripcion of the Prior Art 



With respect to securing communication, enti- 
ties are often required to electronically authenticate 
themselves before utilizing services or executing 
transactions. This authenticity may come in the form of 
a username and password combination or a certificate. 
To accomplish this feat, these entities must first reg- 
ister their existence either physically or virtually so 
that they might receive a proof of identity. 

Providing the proof, such as a username and 
2 5 password combination, carries out the actual authenti- 
cation. Aforementioned simple authentication schemes 
are unfortunately quite context specific: identity 
based on username and password may be totally insig- 
nificant in all other circumstances. Moreover, such 
proof does not irrefutably distinguish different enti- 
ties . 

Digital certificates or electronic identities 
are electronic files that are used no uniquely identify 
people and resources over networks such as the Inner- 
35 net. With help of digital certificates it is possible 
to make secure, confidential communication between two 
parties, when one travels to another country, his/her 



passport provides a universal way co establish your 
idencicy and gain encry, Digiral cer^if icaties provide 
similar idennif icat ion . Cemficanes may be issued by a 
crusred third party (TTP) such as a Cert if icacioa 
Authority (CA) . Much like the role of the passport of- 
fice, the role of the crusted third party is to vali- 
date the certificate holders' identity and to "sign" 
the certificate so that it cannot be forged or tampered 
with. Once a TTP has signed a certificate, the holder 
can present their certificate to people, Web sites, and 
network resources to prove their identity and establish 
encrypted, confidential communications , 

A certificate typically includes a variety of 
information pertaining to its owner and to the TTP that 
issued it. This information can be as follows. The name 
of the holder and other identification information re- 
quired to uniquely identify the holder, such as the URL 
of the Web server using the certificate, an individ- 
ual's email address or the holder's public key. The 
public key can be used to encrypt sensitive information 
for the certificate holder; the name of the Certifica- 
tion Authority that issued the certificate; a unique 
identifier; the validity period (or lifetime) of the 
certificate (a start and an end date) . 

In creating the certificate, this information 
is digitally signed by the issuing TTP. The TTP * s sig- 
nature on the certificate is like a tamper-detection 
seal on a bottle of pills - any tampering with the con- 
tents is easily detected. Digital certificates are usu- 
ally based on public-key cryptography, which uses a 
pair of keys for encryption and decryption. With pub- 
lic-key cryptography, keys work in pairs of matched 
"public" and "private'* keys. In cryptographic systems, 
the term key refers to a numerical value used by an al- 
gorithm to alter information, making that information 
secure and visible only to individuals who have the 
corresponding key to recover the information. 
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The public key can be freely disnrxbuted with- 
out: compromising che private key, which muse be kept 
secren by its owner. Sxnce these keys only work as a 
pair, an operation (for example encryption) done with 
the public key can only be undone (decrypted) with the 
corresponding private key, and vice-versa. A digital 
certificate securely binds your identity, as verified 
by a trusted third party (a CA) , with your public key. 

A CIA certificate is a certificate that identi- 
fies a Certification Authority, CA certificates are 
just like other digital certificates except that they 
are self -si^rxed . CA cercif icanes are used no determine 
whether to trust certificates issued by the CA. 

In the case of a passport, a passport control 
15 officer will verify the validity and authenticity of 
your passport and determine whether to permit you en- 
try. Similarly, the CA certificate is used to authenti- 
cate and validate the Web server certificate. When a 
Web server certificate is presented to a browser, the 
20 browser uses the CA certificate to determine whether to 
trust the Web server's certificate. If the server cer- 
tificate is valid, the secure session proceeds. If the 
server certificate is not valid, the server certificate 
is rejected and the secure session is stopped, 

digital environment the contemporary 
equivalent of an identity card is a certificate: a con- 
firmed proof of an entity's distinct identity, a cer- 
tificate typically does more than just confirms attrib- 
utes of its subject. The most common use of (public 
key) certificates is to bind an entity* s public keys to 
its identity. These keys can be used to various pur- 
poses such as providing authentication, authorization, 
confidentiality, integrity, or non-repudiation. 

Theoretically certificates are not conte:?ct 
35 specific but in practice different uses require differ- 
ent certificates. E.g. standard X.509 certificate does 
not include e-mail address information that is required 
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in secure eleccronic mail (e.g. PGP or S/MIME) . Simi- 
larly other applications may need to have their own 
proprietary attributes included in certificates. .Al- 
though this inclusion of atcrxbutes is noc problematic 
5 per se, new certificates need to be created. 

US patent 5,982,898 describes a method for is- 
suing a short term certificate for a person who already 
has a previous certificate. The new certificate is is- 
sued after the validation process of the ownership of 

10 the previous certificate. The validation is done by 
separating che tasks of identity verification and cer- 
tificate issuing, which allows a disassociating of che 
long-term binding between the person and his/her pub- 
lic/private key pair. This is accomplished by a regis - 

15 tration authority issuing a password to the person once 
it is satisfied of person's bona fide. Thereafter, 
whenever the person wishes to have a new certificate or 
eleccronic identity, che person contacts a certifica- 
tion authority, identifies itself with the password and 

20 obtains a certificate. The certificate typically in- 
cludes person's name and a public key xn plaintext, and 
a signature. The signature is derived by hashing the 
plaintext portion of che certificate to obtain a value, 
and encrypting the value with the CA's private key. 

order to get a certificate or some ocher 
electronic proof of identity a subject must prove and 
register its existence co some authority, if che same 
identity needs several proofs for different uses, this 
repeated registration procedure would become quite in- 

3 0 convenient. 



STJMM^V OF THE INVEMTIQN 



The purpose of this invencion is to provide 
3 5 means to use a previously certified identity to create 
another representational form for the same identity. 
This representational for can be expressed as an elec- 
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nronic identity, a cercxficace, or a cercif icaced ac- 
cess CO a service or a server. This way an encicy, chac 
can be defined as a recipient of a electronic identity 
or a certificate or a holder of a certificate, can ex- 
tend his, her or its already verified identity for 
other uses. The previously certified identity can be 
for instance so called mobile identity which is associ- 
ated to a person's mobile terminal such as mobile 
phone. The person can show to certificate be his/her 
own by using the digital signature feature of the mo- 
bile terminal. 

In che following is an example o£ the steps of 
the identity extension process according to the present 
invention. Note chat che entities and devices m che 
15 process descripcion are listed by their role and may 
not be distinct ones in practical implementations. 

An encity needs to be authenticated in a con- 
text where it. does not have a previously confirmed 
identity. The entity or authorized representative sup- 
plies optional information chat is appended to verified 
facts provided by registration auchoricy chat knows che 
encicys mobile idencicy. 

This information and an idencif icacion request 
is sent to the mobile identity regiscracion auchority 
2 5 wich routing info co che receiver of identification and 
also to che cerminal equipmenc chat contains che means, 
i.e. signing keys co prove che previously confirmed mo- 
bile idencicy. Based on idencif icacion requesc cype 
regiscracion auchoricy appends optional sender- supplied 
accribuces to verified data chac ic possesses and for- 
wards chese co che specified terminal equipmenc. if the 
identity cannot be resolved from che cerminal routing 
info, che process cerminaces. 

The encicy or auchorized represencacive in- 
speccs che accuracy of idencif icacion response informa- 
tion on che cerminal equipmenc and if he, she, or ic is 
sacisfied with ic, digically signs che response afcer 
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Which ic is senc back no regiscracion auchoricy. if 
idencificacion type requires addicional guarantees, 
e.g. certification, registration authority acquires ap- 
propriate confirmation from providers of chose serv- 
ices. Confirmed identity information is sent to the re- 
ceiver address specified in the original identification 
request . 

Compared to previous registration and certifi- 
cation schemes the mosc obvious benefit is that the 
present invention offers the same amount of trust chat 
a local registration office is capable of providing 
wichouti 1C3 physical and other conscraints. The equiva- 
lence of trust holds on condition that the registration 
authority possesses or has access to corresponding in- 
formation, i.e. its private databases or databases of 
other authorities such as Finnish Population Registry 
Center. On the other hand there are also attributes, 
such as access to a certain e-mail address, thac can be 
confirmed by virtual means even if these are not re- 
20 corded in advance. 

If mobile identity and equipment is used in- 
stead of e.g. a terminal equipped with a smart card 
reader, the solution of the present invention is to- 
tally location independent. An entity can confirm its 

2 5 Identity and acquire a new identity whenever and wher- 

ever it is required and is not constrained by the 
available hardware and software provided that the re- 
cipient is capable of receiving the affirmation. Al- 
though Che solution does not disallow the use of public 
30 mobile terminals (i.e. somebody else's phone J , mosc 
likely Che terminal that is used in authorizing the 
identification response is an entity's own. Conse- 
quently an entity is not required to perform sensitive 
operations, such as encering a signing pin, on dis- 

3 5 trusted devices. 

Essentially the invention is intended for ex- 
tending an entity's identity based on an existing mo- 



bile certif icane and ocher verified and confirmed 
faces- The one of che most apparent and praccical func- 
tions is to use this information to issue new certifi- 
cates for varxous uses such as secure e-maxl, PGP or 
5 S/MIME, The mobile variant of the solution, however, 
does not have to be as limited. Since the ability to 
provide confirmed facts about an entity is totally mo- 
bile, in certain situations certificates are not a key 
issue. Say, if mobile identity registration authority 
10 has access to Finnish Population Registry Center's da- 
tabase it can provide confirmed home address, marital 
status, or whatever ia required. 

BRIEF DESCRIPTION OP THE DRAWINGS 

15 

The features, objects, and advantages of the 
present invention will become more apparent from the 
detailed description set forth below when taken in con- 
junction with the drawings wherein: 
2 0 FIG, 1 is a block diagram of a system of the 

present invention; 

FIG. 2 is a flow diagram in accordance with 
one embodiment of the invention; 

FIG. 3 is a second flow diagram in accordance 
2 5 with one embodiment of the invention 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 



Figure 1 presents one example of the preferred 
system according to the present invention. The system 
of figure 1 includes mobile station MS which is con- 
nected through the communication network CN to the Cer- 
tificate Authorxty CA server. Also the system includes 
a terminal including for instance a web browser. The 
terminal is connected through the communicat xon network 
CN to the server of CA. The mobile station concaxns 
means for digital signing a message or character 
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scring. Digical signing means ^are certified with at 
least one certificate which enables the user to authen- 
ticate more certificates. This previous certificate can 
be a mobile certificate which is mentioned above. 
5 Referring further to figure 1 it is described 

one preferred solution of the present invention. This 
solution IS described in the context of certifying a 
new PGP key pair. 

In this solution the following assumptions are 
10 made. The mobile phone's SIM card-signed PGP key packet 
only "lives- for a short time (a few minutes) in the 
system and is then thrown away. If it is logged it can 
be used for journalizing the transactions m the issu- 
ing process. Also it can be logged perhaps for keeping 
track of errors. If chere were to be any permanent re- 
tention of this packet (for legal or other purposes), 
it would have to comply with some existing standard 
format, in order to be assured that it could be ac- 
cessed and correctly interpreted in the future. 

As described here, the format of the phone - 
signed PGP Jcey packet does not fit any existing stan- 
dard. If necessary, a standard format could be de- 
signed, and the SIM card software would be required to 
create signatures in this format. The user has control 
(physical security) of the PC and corresponding PGP 
private key used for performing the operations de- 
scribed here. The CA operates a publicly accessible PGP 
keyserver containing all of nhe PGP keys that the CA 
has signed. 

Here we describe the steps to follow in order 
to use the applicants S3 system to securely sign a PGP 
key by the WPKI CA (WPKI, Wireless public key infra- 
structure), using a user's S3 SIM card to Imk the sig- 
nature back CO the proof of identicy that was presented 
to the WPKI Local Registration Authority. This process 
is performed without breaching the anonymity of che 
user-s SIM card Network ID. As described here, che pro- 
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cess is snaceless on che CA end. reducing complexxcy 
and increasing resiliency of che protocol for che CA. 

At first software using PGP on che PC displays 
the name and PGP key fingerprint of the user that is no 
be certified on the PC screen. Also displayed on the PC 
display is a prompt to enter the 4 digit number on che 
mobile phone display. 

The PGP key fingerprinc is a crypcographical ly 
strong hash of che key. PGP users are accustomed co 
verifying keys by comparing key fingerprints, so chxs 
makes it easier co verify the PC-Phone link xs reli- 
able, and not being attacked by an intruder insercmg a 
fake message co be signed by che phone. The latter is 
probably not necessary to protect against, since we as- 
15 sume physical security for chac link. However, che link 
is noc necessarily secured. 

The PC sofcware communicaces with the phone 
through che wired or wireless incerface or ocher appro- 
priate interface, and passes a message packec (TBD) 
2 0 containing a command co stare the PGP key signing proc- 
ess. Phone generates and displays a four digic random 
number, along wich a prompc co cype this number into 
che PC if Che user wanes co sign his PGP key wxch his 
phone key . 

*^^® phone displays a 4 digic random number 
chac Chen muse be manually entered into che PC's key- 
board. This prevents a daring (high probability of de- 
tection) accack from a hoscile device chac mighc be 
communicating wich che phone, and crying co crick ic 
into signing a "What is my name?- message chac could be 
used CO compromise the NID's anonymnicy. 

Then user types in che 4 digic number from che 
display on che phone mco che PC, as requested by che 
screen prompc . 

On che PC, che sofcware cakes che 4 digic ran- 
dom number encered by che user, and sends in wich a 
message, incended co be senc co che CA, requesting 
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{from the CA) a User ID lookup for a phone NID nhac 
signed che requesc , In ocher words,' a "What is my 
name ? " reque s z . 

The phone compares the random number sent wxch 
Che "What as my name?" request, and if it matches, dis- 
plays a warning that it is about to sign a PGP key with 
its key. 

PC displays a lengthy legal notice to user, 
warning chat user is about to sign their PGP key wxth 
the phone's key and that the user is contractually ob- 
ligated to only make this signature if he is the owner 
of both keys. Again, if the random number matched, the 
"What is my name?" message is signed by the phone, re- 
turned to the PC through the serial interface, and 
IB saved for transmission to the CA, The PC software gen- 
erates another message, intended for transmission to 
the CA, this message contains the key fingerprint, and 
a request to the CA to sign the attached key, if the 
fingerprint matches. This is a "Sign this User ID and 
key, please," request. The "Sign this User ID and key, 
please." message is then passed to the phone through 
the serial interface, with a request that the phone 
sign the packet, using the its SIM card private key. 

The PGP key fingerprint is displayed on the 
2 5 phone at this point and verified by the user to be in 
agreement with the PGP key fingerprint on the PC 
screen. The user is prompted to OK the signature, if 
the fingerprint matches. The User's phone sends the 
signed "Sign this User ID and key, please." packet back 
through the serial interface to the PC [along with the 
phone key ID that signed it] . Save on the PC for later 
transmission to the CA. The PC-Phone connection is no 
longer needed after this point, and is dropped. 

Note that if desired, the process described in 
the preceding few steps could be accomplished with only 
one signed message from the phone. This message would 
contain a signature of the PGP key fingerprint. The one 
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message would be used with two different meanings, 
first to asK the CA, "What's my User' ID (name)?", and 
second to command it to "Sign this Key and User id 
please". In the first case the PGP key fingerprint is 
5 ignored, since only the phone's NID is need to specify 
what name is desired from the CA. 

The PC opens up a secure channel (using TLS) 
to the Certification Authority, The PC sends the SIM- 
signed request for User ID ("What's my User ID and 

10 name?") query to the CA over the secure link. 

The CA looks up the phone ' s owner m the con- 
fidential database, and sends the User ID for the phone 
back to the PC, as requested. This is the WPKI User ID 
that the phone's owner had certified at the LRA. Send- 

15 ing this information to the PC does not breach the ano- 
nymity of the NID, since the link is encrypted and the 
phone owner is the one making the request , 

The PC checks to see if the returned WPKI User 
ID is present on the users PGP key. If it is, then the 

20 process proceeds to the next step, automatically. If 
the returned WPKI User ID is not present on the PGP 
key, then the User ID is added to the PGP key before 
proceeding . 

If the WPKI User ID must be added to the PGP 
25 key, we branch off at this point and follow the normal 
PGP procedure for adding a new User ID to one's key- 
ring. The user must supply an email address for this 
User ID, because the User ID supplied by the CA will 
not have an email address. 

Since the ultimate result of this process will 
be publication of the signed key on a public key server, 
the User ID must be self -signed. PGP User IDs are only 
suitable for publication if they are signed by the 
keys owner. 

The PC next uses the user's PGP private key to 
sign the »'Sign this key, please. request to the CA 
(this request is asking the CA to sign the phone 
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owner -s PGP key. remember). This requesc wa. signed 

earlier by che phone's SIM card. 

This Signature shows the CA chac che requestor 
is the one who controls the PGP private key component, 
and is not sending someone else's key for certxfica- 
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The PC sends the PGP and Phone signed "Sign 
this user ID and Key, Please." request packet with the 
corresponding PGP key up to the CX, through the estab- 
lished TLS link. Again, this packet links the phone 
owner's (presumably anonymous) NID w.ch the public PGP 
identity, so the channel must be encrypted. 

The CA checks the PGP signature. The CA checks 
the phone key. The CA then checks in its confidential 
IS database for the User ID associated with the phone that 
signed the "Sign this Key, Please.- request. The sub- 
mitted PGP user ID (name portion) must match with the 
CA's phone 's user name. This will be the case, because 
we 3U3t added the User ID returned by the CA for this 
20 NID to the PGP key we attached to the message. 

If the submitted User ID for this phone is not 
found in the CA's confidential database, the request is 
denied, and an error message is sent back to the PC. 
For debugging purposes, this error message could con- 
25 tain the correct User ID, since we are operating over 
an encrypted channel. The user is informed of the prob- 
lem Via an error message displayed on PC If che name 
portion of the User IDs match, then the CA signs the 
PGP key With the CA key and discards che "Sign this 
30 key. Please" request with the phone NID. It then in- 
serts this information into the confidential database. 
The CA-signed PGP key is added to a -Pending PGP Cer- 
tificate" database on the CA. 

The CA then emails the CA-signed PGP Key to 
3 5 the email address specified by the user in the User ID 
that was Signed by the CA. This provides a check that 
che email address is correct. This certificate is en- 
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crypned by che public encrypcion key of chac user. Thac 
way if nhe email address curns oun co be wrong, and che 
key IS misrouted, in will likely never be decrypted by 
anyone , 

5 The CA expeccs che user co decrypt and re- 

upload Che signed key back up to che Ch, chus proving 
Chat che email address was correct, and che person re- 
siding ac chac email address has che capabilicy of de- 
crypcing wich chac key. When the CA receives chis key 
10 back from che user, che CA purges it from che Pending 
PGP cercificace dacabase . To overcome email delivery 
problems, periodically che CA will repeac che previous 
seep uncil che user responds or uncil che CA decides co 
give up. 

when che CA receives chis key back from che 
user, che CA publishes che resulcanc signed PGP key on 
Its PGP key server. The PGP key is signed only wich che 
LRA-verified User ID, of course. None of che ocher 
UserlDs chat che user might have on his PGP key are 
20 Signed by the CA. Note also thac che telephone NID is 
not part of the PGP key. nor is it published with che 
PGP key, so we are still procecting che user's NID- 
relaced anonymicy. 

Figure 2 presencs one example of che flowchart 
25 of Che presenc invencion. Firsc che need for any addi- 
tional daca is checked, acace 21. The addicional data 
can be user's current and previously issued certificate 
or some other information like the name or che e-mail 
address of che user. If any addicional information is 
30 needed then che user will provide ic, scace 22. Then 
che requesc for idencif icacion is senc co che regiscra- 
cion auchoricy CA, scace 23. According the idencicy in- 
formacion che exiscence of any previous idencities is 
searched, scace 24. This search can be made in che pri- 
35 vace databases of the registration authority or data- 
bases of other authorities. If any previous idencicies 
is found then a response is created and sent to speci- 
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fied cerminal, stace 26. If any previous xdenticies is 
noc found chen che informacion needed . is acquired from 
the user- If che user accepts the response he or she 
Signs ic digitally and sends in back co registration 
auchoricy. states 27 and 28. If any additional guaran- 
tees are required then those can be acquired from ap- 
propriate authorities, states 29 and 210. Finally che 
confirmed identity information is sent co specified re- 
ceiver, state 211. 

Figure 3 presents one example of che certifi- 
cate of the present invention. The certificate contains 
a number of informacion, which are required for the 
identification. Typically such information are certifi- 
cate identification number, user name, users e-mail ad- 
15 dress, RSA/DSS keys, the fingerprint of the signature 
or of the certificate itself, the hash of the 
passphrase. che signature, and the expiration dace of 
the certificate . 

The prevxous description of the preferred em- 
bodiments is provided to enable any person skilled m 
the art co make or use che present invention. The vari- 
ous modifications to these embodiments will be readily 
apparent to chose skilled in the art, and the generic 
principles defined herein may be applied co other em- 
25 bodiments without the use of che invencive faculty. 
Thus, the present invention is not intended co be lim- 
ited CO che embodiments shown herein but is to be ac- 
corded the widest scope consistent with che principles 
and novel features disclosed herein. 
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